The following is a complete list of known errors in the first edition of COMPUTE!'s Mapping the Commodore 128:
p. 53 The last sentence in the discussion of location 153/$99
should say that CLRCH resets this location to 0/$00, not
3/$03.
p. 54 The last sentence in the discussion of location 154/$9
should say that CLRCH resets this location to 3/$03, not
0/$00.
p. 98 In the example program, the instruction at address 0D2E
should be LDX #$04 rather than LDA #$04.
p. 199 The comment following the instruction at address 1681 should
state that the execution routine is at $1688, not $1866.
p. 207 The table of statement dispatch addresses begins at
18318/$478E rather than 18172/$46FC. The table of function
dispatch addresses begins at 18392/$47D8 rather than
18317/$478D.
p. 290 The third vertical column in this figure should be labeled K0
rather than K6. The key in the top row of that column (row
R7) should be 1 rather than 4. The number keys in columns K0-
K2 are the ones on the numeric keypad.
At the top of the table, the Decimal address of CIA #1 Port A
should be 56320, not 56322 as shown.
(This added by SYSOP BK, Q-LINK)
p. 424 The last sentence in the second paragraph of the entry for
location 65280/$FF00 should read: To set up this arrangement,
use LDA #$0E:STA $FF00. The text instead has LDA #$0F.
p. 457 The explanation of how to perform a VDC copy operation is an
accidental duplication of the procedure for performing a
fill.
The proper steps for a copy are as follows:
1. Set bit 7 of register 24/$18 to %1 to indicate a copy
operation.
2. Load registers 32-33/$20-$21 with the starting address of
the area from which the data is to be copied (the source
area).
3. Load registers 18-19/$12-$13 with the starting address of
the area to which the data is to be copied (the
destination area).
4. Store the number of bytes to be copied in register 30/$1E.
This will initiate the block copy operation.
should be 2580 rather than 2780.
p. 501 The numbers in the expansion bank register setting table are
misaligned. All the numbers in the Expansion Bank column
should be shifted down one row.
p. 507 In the example machine language program, the instruction at
address 1424 should be INC $FE rather than INC $FD.
p. 645- All those entries in this appendix with the form note/not are
647 missing sharp and flat symbols. For example, the second note
(with a frequency of 34.65 Hz) should be designated C sharp/D
flat. The fourth note should be D sharp/E flat, and so forth.
p. 655 The decimal value of the 128's RS-232 status register
(corresponding to location 663/$0297 on the Commodore 64)
should be 2580 rather than 2780.
p. 689 The hexadecimal value of the entry address for the Kernal
BASIN routine should be $FFCF, not $FFCE.
----------------------------
An idea
From : Phil Heberer
I've been tossing around an idea for several years, but *my* programming skills are awfully rusty and may not be up to the task. What I want to do is adapt a C128 for use by handicapped kids as a communication device - probably written, unless SAM speech synthesis could be incorporated. Here in San Antonio, we have a non-profit group called CAMP (Children's Association for Maximum Potential) that offers support for familes with children that have Cerebral Palsy (*VERY* limited motor skills!)
What I envision is a simple text editor with some sort of scanning across the alphabet that could be controlled with a joystick port input. Simple common phrases could be used like choosing taglines in an OLR. I would prefer to do this on a 128 80 col screen where the screen could be split to display the alphabet at the top, with data entry on the lower half. Once the text is composed, there needs to be command to send the output to a printer.
Since movement is very difficult for these kids, input needs to be kept extremely simple. What I envision could use no more keys than the sort of external numeric keypad we used to use on the C64.
Anyone want to toss around this idea and see what we could come up with? I have some spare equipment I could donate, and I KNOW it would be appreciated! BTW, nearly all of these kids are also Air Force military dependents that will also be my patients (I'm going to work in the Orthotic Lab at Wilford Hall USAF Medical Center on Monday). I design and build back braces, leg braces, etc. and will be teaching for the Air Force Tech Training school for anyone who might be interested. ALL input/ideas welcome!
---------------------------
Ipaint
From : RAYMOND CRUZ
After seeing numerous questions regarding .Gif viewing on the C128's, I decided to post the below information for everyone, since quite a few appear to need it.
I Paint: -------
A drawing/painting program that allows over 65,536 colors and a 640x400 display. It uses interlace & needs a C128 with 64k video ram & 80 col. monitor,it also supports over 50 printers including, color,laser,bubble jet, thermal, and dot matrix. It has support for the mouse as well. It is as powerful as many of the Amiga/IBM programs I have seen.
I Port:
This is an I Paint Graphics Manager to allow you to import other graphic formats into I Paint. It offers 8 import options: Amiga IFF, HAM, and EHB Koala GIF MAC GeoPaint Basic 8 Doodle Printshop
Plus allows export options of I Paint files to Gif files.
I have converted 640x400x256 gifs successfully with no loss of colors, where GDS would crap out. One of my Conversions has been distributed by Rick Kane (author) its called ip.bodyglove. Its available on GENIE. My name there is Anthony Cruz.
I Paint 1.5 is $39.95 I Port 1.54 is $29.95 Save! Both is $59.95 I Port update $10.00 with original I Port disk.
These programs are available from:
Living Proof, Ltd Dept. C1 PO Box 80714 Minneapolis, MN 55408-8714
The heart and soul of I Port is its powerful Equalizer. This equalizer allows you to have full control over the colors during the conversion, meaning that those certain GIFs that come out horrible on other converters will now be able to be "Color Corrected" with I Port.
The equalizer takes some time to learn, but when you do learn how to use it, you acquire a very useful tool. I used the equalizer to do that ip.bodyglove picture that you see on Genie. It was originally a 640x480 GIF with 256 colors :)
Another advantage is some GIFs are interlaced and Rick Kane (I Paint author) has created a program called de-lacer that will convert that GIF from an interlaced GIF to a regular GIF. This opens a lot of doors for you :>
If you decide to get the program contact Rick Kane and when you order it from him ask him if he can include the De-lacer to save you a long distance call to 221 baker st. I have over 1000 GIFs on my hard drive that I have sucessfully converted to I Paint using I Port, its a great program. If you get it and need any help, just hollar. I beta tested a lot of the I Paint/I Port stuff for Rick, so I know I Paint and I Port inside out by now :)
-------------------------
Re: .MOD files
From:(Nate Dannenberg) Date: 6 Dec 1995 05:52:41 GMT
Just letting you all know that I have a modplayer I wrote for the C128+REU+Stereo SIDs. This program will be available thru Threshold Productions in about a month, for about $30.
Included in the package will be drivers and modes for mono or stereo SIDs, in 4 or 8 bit resolution, plus drivers for Shaun Halstead's Surround-SID board, and my 4-track digiboard (available soon thru TP).
Watch this space for details, and be sure to Email me if you have any questions regarding this software.
Sometime there will be a C64 version available, and if time, money, and luck permit, there will be a Super64 version written to take advantage of what this 10/20 MHz card has to offer (such as 8 to 32 track playback, sample rates in excess of 44KHz, etc.)
Also, there my be a version available in the future, for expanded C64's and 128's that have the internal 1MB of ram installed (right now, the program needs an REU to run...just not enough memory in the C64 to hold the average 200K to 400K file)
------------------------------
Ace15
From : Ismael Cordeiro
Geoff Sullivan writes:
GS> However I cannot get MY geocable setup to work. I've read
GS> and re-read the docs on how to set the paramaters in the
GS> config file to utilize the geocable, but I must be missing
GS> something because I can't get it to work in ZED. It works
GS> fine in Geos though. Have you tried it?
ACE15 works fine with Geocable out-of-the-box. No need to change anything. What happens is that the present version of ZED doesn't have all features implemented and the print one is among them. In the docs for ZED there is a list of commands. The ones available in the present version have an asterisk preceeding them.
For printing with the Geocable you have to copy or redirect the file to drive u, the user port, and you have to pay attention to two things. First, since there is no interface for translating PETSCII to ASCII you have to send ASCII to the printer. Second, most printers default to not adding a LF to CRs, so you have to send to the printer ASCII-CL (MS-DOS and CP/M) or ASCII-LF (Unix). Other possibilities are setting your printer to add LF but that will reflect in the settings of all your other programs, or turning on the LF switch in the Geocable, if it has one.
The command for printing ASCII-CL and ASCII-LF files is:
cp filename u:
or
cat filename >u:
The command for printing ASCII-CR files is:
tr -ac2u filename >u:
Other options that give the same results are -ac2a, -ac2al and -ac2m.
The command for printing PETSCII files is:
tr -p2u filename >u:
Other options that give the same results are -p2a, -p2al, -p2m, -c2a, -c2al, -c2u and -c2m.
------------------------------
Programmin'
From : Rod Gasson
Myke Carter writes:
MC> I would like to make an 80-column C128 version of a C64 program that I'm currently working on but do not have the equivalent manuals necessary in order to learn the correct POKE locations for some of the core functions of my C64 program. I recently learned that to do the standard C64
Hmm, one of the first things you'll need is a cross reference guide. Jack VanderWhite can supply such a list. Contact him for details.
MC> my C64 program. I recently learned that to do the standard C64 screen/border colour changing POKEs (at 53280 and 53281) on the C128, I must first select BANK 15.
Bank15 happens to be the C128's default bank. You rarely need to issue this command (at least not from BASIC)
All VIC and SID registers are the same for both the C64 and the C128, however, the 80 column screen doesn't use VIC so for your purposes forget that it exists.
MC> I dug out my C128 Programmer's Reference Guide and read as much as I could about the C128's bank structures, but it seems to assume a general understanding about what the banks are all about in the first place.
Actually, you'll find that none of the reference guides or memory maps are much better. They are confusing.
MC> I really doubt that this BANK thing is going to be really difficult for me to understand if I can get off to a good
MC> start using them.
I'll help as much as I can.. and no, they are not difficult to understand.. in fact, if you are using BASIC you can forget they exist.
MC> What is the purpose for having 2 64K banks that are split into 8 16K video banks and whatnot
This is all related to ADDRESSING, so I'll start here.
The C64:
The 6502 CPU is capable of addressing 64k of memory .. from $0000 through to $ffff.
The VIC chip is "mapped" into the i/o block at $d000 .. for technical reasons it can only "see" 16k of memory at a time. Most C64 programmers are aware of this, so I'll not explain why. The 16k "block" of memory that VIC sees is called a "bank" (or video bank). There are 4 such "banks" that can be used since there is only 64k of memory available (however, not all of these banks are usable, for other reasons) The C128: The VIC is the same as the C64, so it too can only address 16k, and again, each 16k "block" that it can address is called a "bank". Since we now have 128k of memory you have up to 8 "banks" to choose from.
The C128 uses the same CPU as the C64 (well, almost the same), and as such it too can only ADDRESS memory in the range $0000-$FFFF .. ie. 64k. Since the computer is advertised as having 128k of memory the designers got smart and added what they call a MMU chip (Memory managment Unit).. This chip enables blocks of RAM to be switched in and out.... there are two such blocks in the C128, and just to confuse things, CBM also called these blocks "banks", namely BANK#0 and BANK#1. Each bank consists of 64k of RAM and the CPU can address one OR the other of these banks, but not both at the same time, as it can still only address from $0000-$FFFF.
Now the fun part ;-) First up *forget about the video "banks"* I am only considering the "banks" that relate to the CPU.
RAM is no good without an operating system, and just like the C64, this operating system (the KERNAL) is in ROM.. the poor ol' CPU can still only address 64k, so this ROM must be mapped in or out as required (just like the C64). With the C128, with the O/S switched in in place of RAM (its usual startup configuration) the designers called it BANK#15. IOW, bank#0 will have the CPU looking in one entire chunk of 64K RAM, bank#1 will have it looking in another chunk of 64k RAM, and bank#15 has it looking in most of bank#0 ram PLUS the ROMS. Again, this is very similar to the C64, except that we have now given it a bank number. On the C64 we consider this the "normal" state of affairs and treat "the underlying RAM" as something mysterious.. essentially its the same thing.
Now that we have banks#0, 1, and 15 sorted out it is only fair to mention that there are other "banks" .. we still only have the two blocks of 64k RAM and the ROM to deal with, but these other banks allow different combinations of each.. for example, bank#1 RAM PLUS the ROM, is bank#14.
Hopefully you follow that.
MC> and then how does the 64K video chip play into all of this?
In 80 column mode, the VIC chip isn't used (which is why I said to ignore the "banks" related to this). You can forget everything to do with the VIC chip. In this mode, the video is controlled by the VDC chip, but unlike the VIC chip, the VDC chip has its own RAM.
MC> Does that effectively make a C128 into a C192
Yes ! :-) A C128 with a 64k VDC chip is indeed a 198k computer.
MC> or is it shared in part or whole with the previously established 128K RAM - or what?
It is completely isolated... in fact it is so isolated that it can be a real PITA to deal with. This VDC ram is ONLY addressable via 2 locations, at $D600 and $D601.. you place the value you wish to store into D601 and the register you wish to store it to into $D600. It is like performing surgery through a keyhole. If you are only using BASIC, then regular PRINTs and other control codes (such as chr$(147) to clear screen) works fine, so you may not need to know any of this.
MC> First and foremost, I need to know where the pointers are for the start of BASIC,
45, 46 (decimal) (Bank#0)
MC> start of variables,
47,48 *note* BASIC variables are stored in BANK#1
MC> start of array variables,
49,50
MC> start of free RAM, and
51, 52
MC> end of BASIC are.
Sh*t, this one gets me every time... up around 4000 from memory.
MC> My program changes the values in these locations frequently and simply cannot function without them. Do I just precede all of these POKEs with a BANK15 statement and pretend that it's still a C64 (I doubt it!) or what?
Your biggest problem is gunna be the variables. What you are suggesting won't work because bank#15 is bank#0 RAM plus ROM.. the C128 BASIC variables are stored in BANK#1 ram.. To retrieve data from here you'll need something like this.
10 print "this is an intro the computer is in bank#15 at startup"
20 bank#1 :REM you wanna get data from bank#1
30 a=peek (location) : a$=chr$(a)
40 bank#15 :REM switch the roms back in.
50 print a$
I'm not gunna guarantee this will work though, cos switch to bank#1 is switching the ROMS out, so the program may crash (I forget what safeguards BASIC has for this). You *should* be safe by using bank#14 in line#20 (which will give you bank#1 RAM and ROM), but you will of course only be able to read locations below the ROM address ($4000) .. problem here is that variables are stored way up high.
Well, I dunno if this is of any help.. and I *Hope* I haven't confused you any more than need be.
